IBIS Macromodel Task Group Meeting date: 30 May 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen Liwei Zhao Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Note: The meeting scheduled for May 23rd was not held. ------------- Review of ARs: Arpad: Send an email announcing the ATM task group's recommendation that SPIM continue on the track toward being included in IBIS. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 16th meeting. Ambrish moved to approve the minutes. Lance seconded the motion. There were no objections. -------------- New Discussion: AMI Support for [Test Data]/[Test Load]: Michael said he thought providing Test Load information in the AMI context would be straightforward. However, he thought Test Data in the AMI context would would require more effort. In addition to providing waveforms representing impulse responses or blocks of GetWave data, we would have to provide data such as the unit interval and sample interval (i.e., samples per bit), which typically are set by the user. Michael described three types of data we need to provide to define the Test Data conditions: 1. Waveform data representing the inputs and expected outputs from the AMI_Init or AMI_GetWave functions. 2. Data such as the unit interval and sample interval, which are typically configured by the user and passed to the model via the tool. 3. A specification of the specific settings of the AMI parameters under which the expected output was generated. Michael said one initial question for the group was whether we should introduce a new format for the new types of data required or attempt to adapt the existing AMI parameters structure to accommodate the new data. Arpad said the existing [Test Data] includes waveforms, and he asked how this would be different. Michael said the existing [Test Data] provides information at the pad or pin. For AMI, we want to provide reference waveforms to compare to the filtered waveforms returned by the AMI model's Init or GetWave calls. Arpad referred to his recent presentation on the possible interactions between the block size of the AMI_GetWave call, which is defined by the EDA tool, and the adaptation time constant of an AMI Model that continued to adapt its Output thresholds and sampling offsets even after Ignore_Bits. He said there was an interaction between a tool chosen value (block size) and the Model, and he had suggested that it might be helpful to give the model maker a way to specify the recommended block size. He said information we specify in Test Data might be a helpful step in that direction. Arpad asked what we might specify for golden information. He asked if Michael was considering contour information or eye plot information. Michael said he was strictly considering waveforms, as contour plots and eye diagrams are tool specific proprietary processes that are not standardized. He wanted to stick to raw waveforms that are returned from the model. Ambrish said that given fixed parameter settings, unit interval, samples per bit, etc., different tools should end up producing the same output waveform for a given input waveform. He said he would prefer to use the existing AMI parameter tree structure. Ambrish noted that the details will be important. For AMI_GetWave, for example, we may have to provide a comparison waveform for the first block of data after Ignore_Bits. Michael agreed that we could use the existing AMI parameter structure for specifying the AMI parameter settings, and he agreed that AMI_GetWave testing might involve additional details and assumptions that we have to make. Michael summarized the goal of the proposal: The model maker provides the information. They specify the test load, test settings, and the input waveform. If the simulation ends up with a different filtered waveform at the output than the model maker expected, there is a problem. Arpad said that he often has to go through this process manually to provide correlation information to customers. In general, one might only have a .pdf from the model maker or customer with images of contours, waveforms, eyes, etc. Ambrish agreed that the process is not currently standardized. Wei-hsing noted that given the same .sNp different tools often produce different impulse responses. Arpad observed that in the AMI_GetWave case the output waveform is highly dependent upon the overall bit pattern. One tool might use a different seed, for example. Ambrish agreed and said we need to provide the exact bit pattern as part of the input definition. Michael said he would take the suggestions and work on the proposal. He said his preference was to provide the new information in a separate file. He noted the suggestion to use the existing AMI parameter tree structure, and he noted Ambrish's suggestion that everything including waveforms, etc., should be plain text format. Proposal for a new keyword: [Clock Group] Michael recalled that IBIS 7.1 introduced the [Clock Pins] keyword, which allows the model maker to indicate pins that have a clock pin and clocked pin relationship. Right now, however, the only type of relationship that can be specified is "Unspecified". The point of the [Clock Group] proposal is to start defining the clock relationships. In addition, the current [Clock Pins] keyword makes it hard for the model maker to handle cases where a DQS strobe might be configured x4 or x8 DQ lines, as might be the case for DDR controllers. Michael said work on the AMI Test Load and Test Data had been taking precedence over this proposal. Arpad asked whether [Clock Group] might be considered a higher priority given the pace at which DDR simulation support is advancing. Michael said he wasn't sure, and he thought there might be existing proprietary solutions people were using. Arpad and Michael left it as a homework assignment for people to think about which proposal should be given higher priority. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: None. ------------- Next meeting: 06 Jun 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives